這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境(Situation)、任務(Task)、行動(Action)與結果(Result)。每個故事會拆成三天:第一天談 S,還原當時的情境與我原本的理解;第二天談 T,釐清真正的任務、限制與完成條件;第三天則合併 A 與 R,整理我採取的行動、造成的結果,以及後來學到的事。
上一組故事收在 Day 24|我替成果建立最小交付證據包。最後一組菜雞行為輪到資歷本身:把做過很多次與會用工具當成已經累積經驗。本篇只還原情境;任務留給 Day 26,做法與結果留給 Day 27。
我曾把經驗理解成次數:同類功能做過好幾輪、慣用工具越用越順,年資往上疊。直到被問「上次為什麼這樣設計」,我只答得出「一直都這樣做」。
以下是虛構案例。在粉鳥工單服務,我加過很多次工單欄位:改資料表、加 API、加畫面,一路順手。這次的要求是「報表要能匯出」——資料量大、可能逾時、可能只成功一半。熟悉的三步驟一步都答不了這些問題,我才發現自己做過很多次的,其實是同一種小題目。當時的理解並非全無道理:每次交付都通過,工具也真的越用越快;日常排程只獎勵出貨,沒留回頭檢查判斷的時間。像資深的樣子,是環境與我一起養出的錯覺,不全是怠惰。
重複是同一個動作再做一次;熟練是做得更快;經驗還要多兩件事——知道結果與假設差在哪裡,以及下次會改什麼。我的循環在行動與結果之間就斷了:上線後不回頭對照假設,偏差沒被看見,下一次判斷就沒有材料。
[行動] --> [結果] --> [回饋] --> [反思]
^ |
+------ [下一次判斷] <----------+
這一圈缺了後半段,前半段再多次也只是重複。
選一個近期技術決策,花二十分鐘,依《工程決策回顧表》寫下當時資訊、假設、實際結果、偏差與下次調整,產出一頁內的回顧紀錄。驗收方式:日後重讀仍能重建選擇理由。影響小、口頭回想就夠的決策不必填表。
同樣是 Day 06 那張《工程決策回顧表》,這次填的是結果與偏差那半邊。
對應工具:《工程決策回顧表》。
# 工程決策回顧表
用途:把一次工作決策轉成可修正的判斷。
使用時機:情境一改就不確定怎麼選,或說不出上次為何這樣做時。
| 決策 | 當時資訊 | 假設 | 結果 | 偏差 | 下次調整 |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
提醒:只填會影響判斷的資訊;不放機密、個資與可辨識人物。
如果次數不會自動變成經驗,我該累積什麼,才能在情境改變時仍選得出方案、說得出理由?這是 Day 26|我要累積的不是工具熟練,而是判斷與選擇理由要定義的任務。